Fix: Ignore Content-Length for gzip responses in --download”#1651
Closed
ali90h wants to merge 4 commits intohttpie:masterfrom
ali90h:master
Closed
Fix: Ignore Content-Length for gzip responses in --download”#1651ali90h wants to merge 4 commits intohttpie:masterfrom ali90h:master
ali90h wants to merge 4 commits intohttpie:masterfrom
ali90h:master
Conversation
…oding-with-downloads Handle gzipped downloads without decompression
…t-branch Fix tests and encoding detection
ali90h
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request resolves issue #1642 by updating the download logic to ignore the Content-Length header when the response includes a Content-Encoding value other than identity.
When Content-Encoding is set (e.g., gzip), the Content-Length header refers to the compressed payload size—not the actual number of bytes written to disk after decompression. This mismatch previously caused:
Incorrect progress reporting
False "interrupted" download flags
The fix ensures that when a compressed response is detected, the downloader does not rely on Content-Length or Content-Range values, and instead trusts only the number of bytes successfully written. A corresponding test has been added to verify that gzip-compressed responses are handled correctly.